Field of the Invention
The present invention relates to information handling systems and more particularly to dynamically calculating and applying a timeout value to a manufacturer update service for information handling systems.
Description of the Related Art
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
An issue for information handling systems relates to managing updates to software on the information handling system. This issue is especially important when the software is system software for the information handling system. System software includes the basic input output system (BIOS), other firmware and device drivers. System software is often embedded within the hardware of the information handing system and provides an interface between the hardware of the information handling system and higher level computer programs. Updates to the software can include error (i.e., bug) fixes as well as feature enhancements to extend the functionality of the software. Managing updates to the system software is often an important part of an information technology administrator within an organization employing multiple information handling systems.
Accordingly, a known information handling system supplier provides information handling systems with an manufacturer update package. The manufacturer update package creates a system inventory to report operating system information, target system configuration information, device specific information and version information; performs a comparison between installed system software attributes and a payload of the manufacturer update package to determine applicability of the manufacturer update package; and, executes the update package to apply the payload to update the system software.
However the known manufacturer update package has a number of issues. For example, components of the manufacturer update package architecture are divided into a framework as well as a device inventory and execution (IE) plug-in module. With this arrangement, anything that is device specific, such as how to perform inventory collection and apply the payload to a specific device is part of the device plug-ins. The device plug-ins are implemented on a per device basis. The framework interfaces with the inventory and execution plug-ins via a command line interface (CLI) and an XML data representation. The framework executes the device inventory and execution to perform either inventory collection or update based on the CLI of the inventory that is defined in a file (e.g., a IEConfig.xml file). In the case that execution of the IE modules falls into a dead block, current design of the file will have a timeout value that is hard coded so that the framework process will terminate the child process which launches the IE module so that the update package can exit gracefully.
In the known update package, hard coding a timeout value from each device file is based on anecdotal experience of how long the inventory collection module or execution module will take to execute. The timeout value should not be too long as then the customer has to wait unnecessarily longer to perform a system software update using the update package. However, the preset timeout value may not be long enough to complete the update operation, in which case the update package framework will terminate the IE module based upon a timeout condition and return an error of inventory or update fail.
Accordingly, it would be desirable to provide an update package with an ability to dynamically generate a timeout value based on a customer runtime environment.